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AN  APPROACH  TO  DESCRIBING  THE  FUNCTIONAL  REQUIREMENTS 
OF  AN  EMBEDDED  COMMUNICATION  SYSTEM 

INTRODUCTION 

Most  requirements  documents  for  computer  systems  say  too  little  about  what  to  do  and  too  much 
about  how  do  it.  Their  bulk  consists  of  decisions  that  should  have  been  postponed  until  design  time 
instead  of  precise  information  about  the  system’s  external  behavior.  Designers  are  usually  forced  to 
devote  significant  time  to  clarifying  and  supplementing  the  requirements,  often  making  decisions  that 
they  are  not  qualified  to  make.  Moreover,  they  are  either  constrained  by  poor  design  decisions  that 
have  been  built  into  the  requirements  or  forced  to  glean  essential  system  features  from  a  mass  of 
extraneous  detail.  The  result  of  this  process  is  expensive,  badly  designed  software  that  fails  to  meet  the 
needs  of  its  intended  users. 

In  our  view,  a  requirements  document  should  describe  only  those  demands  that  the  future  system 
must  satisfy.  Its  primary  concern  should  be  the  externally  visible  behavior  of  a  computer  system;  it 
should  not  make  premature  decisions  about  the  system's  design.  Such  a  document  is  useful  to  software 
developers  because  it  permits  them  to  choose  the  most  effective  implementation.  It  is  useful  to  main¬ 
tained  because  it  distinguishes  those  features  of  the  system  that  are  dictated  by  the  requirements  from 
those  that  software  personnel  are  free  to  change  [I]. 

A  requirements  document  must  also  satisfy  other  objectives.  It  should  be  clear,  precise,  easy  to 
modify,  and  easy  to  check  for  completeness  and  consistency.  Moreover,  the  document  must  describe 
any  constraints  imposed  on  the  implementation;  for  example,  the  use  of  specific  computer  hardware 
may  be  required.  Finally,  the  requirements  documentation  must  be  developed  in  a  cost-effective 
manner;  we  should  not  spend  more  money  developing  a  good  specification  than  we  will  save  by  having 
such  a  document. 

In  Refs.  2  and  3  the  term  abstract  specification  refers  to  specifications  that  describe  a  system’s 
modules  without  making  implementation  decisions  (for  example,  decisions  about  particular  algorithms 
and  data  structures).  In  this  report  we  use  the  term  abstract  specification  to  refer  to  requirements  docu¬ 
ments  that  describe  only  what  a  system  is  supposed  to  do,  not  how  it  is  designed  or  how  it  is  imple¬ 
mented.  Thus  an  abstract  requirements  specification  excludes  decisions  such  as  how  the  system  is 
divided  into  modules,  what  particular  data  structures  are  used,  and  sequencing  decisions. 

Despite  their  advantages,  abstract  requirements  specifications  may  not  be  practical.  Few  "real- 
world"  systems  possess  the  simplicity  that  renders  abstract  specification  straightforward.  In  many  cases, 
the  relation  between  input  and  output  is  so  complex  that  the  easiest  way  to  describe  it  is  to  suggest  a 
specific  method  for  generating  the  output  from  the  input,  thus  forfeiting  the  advantages  of  abstraction. 

This  report  presents  the  results  of  a  project  that  applied  the  methodology  of  abstract  specification 
to  a  real-world  system.  The  project  has  two  objectives:  to  determine  the  suitability  of  the  methodology 
for  applications  in  which  the  relation  between  input  and  output  is  complex,  and  to  produce  a  require¬ 
ments  document  as  a  fully  worked  out  model  of  an  abstract  specification. 
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In  this  project,  we  look  two  different  approaches  to  describing  requirements.  Our  initial  approach, 
which  we  call  functional  decomposition ,  required  that  each  system  output  be  expressed  as  a  mathematical 
function  of  inputs.  Because  this  approach  forced  us  to  make  a  number  of  decisions  about  the  software 
design,  we  abandoned  it.  As  an  alternative,  we  formulated  a  new  approach  that  describes  only  what  the 
system  does,  not  how  it  does  it.  Thus  the  new  approach  leads  to  an  abstract  specification. 

To  date,  we  have  completed  a  requirements  document  [4]  based  on  the  new  approach.  Because 
our  system  is  only  one  of  a  class  of  systems  to  which  the  approach  can  be  applied.  Ref.  4  serves  as  a 
useful  model  of  an  abstract  specification. 

In  this  report  we  introduce  the  application,  identify  the  problems  we  confronted  in  specifying  its 
requirements,  describe  our  approach  to  producing  an  abstract  specification,  and  compare  this  approach 
to  a  similar  one  used  in  the  A-7  project  [1,  5],  In  an  appendix,  we  provide  an  example  that  illustrates 
the  formal  techniques  included  in  the  new  approach. 

OVERVIEW  OF  THE  APPLICATION 

The  Submarine  Communications  Package  (SCP)  is  a  small  communications  system  to  be  installed 
aboard  U.S.  Navy  submarines.  The  SCP  performs  several  transformations  on  encoded  message  data, 
converting  it  to  its  original,  human-readable  form  and  then  translating  it  to  the  character  code  required 
for  output.  The  package  will  consist  largely  of  computer  software,  although  some  parts  may  be  imple¬ 
mented  in  hardware.  It  will  be  embedded  [6]  in  a  larger  computer  system  that  may  differ  from  one 
submarine  to  the  next.  Thus,  different  implementations  of  SCP  may  be  required  for  different  classes  of 
submarines. 

Before  being  received  by  SCP,  message  data  go  through  several  transformations.  They  are  first 
converted  from  human-readable  form  to  encrypted  form  and  are  then  forwarded  to  a  transmission  facil¬ 
ity.  The  facility  performs  parity  encoding,  supplies  channel  information,  multiplexes  several  channels 
of  message  data  into  a  single  bit-stream,  and  transmits  the  multiplexed  data  over  a  broadcast  link.  Dur¬ 
ing  transmission,  several  bit  errors  may  be  introduced.  The  message  data  are  received  in  the  radio 
rooms  of  submarines  tuned  to  the  appropriate  frequency.  The  SCP  is  part  of  the  communications  sys¬ 
tem  that  processes  the  received  data. 

The  multiplexed  message  data  described  above  comprise  one  input  to  SCP.  The  radio-room 
operator  provides  other  inputs,  called  configuration  data,  that  indicate  how  many  channels  of  message 
data  have  been  multiplexed,  what  cryptographic  system  is  associated  with  each  channel,  and  which 
channels  of  data  may  be  discarded.  The  significance  of  the  configuration  data  items  is  that  they,  along 
with  data  that  SCP  computes  internally,  determine  what  transformations  SCP  should  apply  to  the  multi¬ 
plexed  message  data  to  produce  the  required  output. 

A  REJECTED  APPROACH:  FUNCTIONAL  DECOMPOSITION 

Our  initial  approach  to  describing  the  SCP  requirements  was  a  traditional  one:  we  generated  a 
functional  decomposition.  Since  the  external  behavior  of  the  system  is  too  complex  to  describe  with  a 
simple  mathematical  expression,  we  needed  to  produce  a  mathematical  description  of  each  function  per¬ 
formed  by  SCP  and  to  indicate  the  order  in  which  the  functions  are  invoked.  The  result  is  the  required 
mathematical  expression  of  the  output  in  terms  of  the  input.  We  succeeded  in  identifying  a  series  of 
functions  that  SCP  could  apply  to  its  input  to  produce  the  required  output,  but  we  encountered  a  prob¬ 
lem  in  trying  to  specify  the  order  in  which  these  functions  should  be  invoked. 

To  understand  the  problem,  consider  two  possible  solutions.  One  solution  assumes  that  the  func¬ 
tions  are  invoked  in  a  particular  sequence.  Its  disadvantage  is  that  assuming  a  particular  sequence  is  an 
overspecification  of  the  requirements.  For  example,  two  functions  required  of  SCP,  demultiplexing  and 
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channel  identification,  can  be  invoked  in  either  order  and  still  produce  the  same  results.  Hence,  the 
order  in  which  the  functions  are  performed  is  a  design  decision,  not  a  requirement,  and  as  such  should 
not  be  included  in  the  requirements  document.  An  alternative  solution,  one  consistent  with  the 
methodology  of  abstract  specification,  is  to  leave  unspecified  the  order  in  which  the  functions  are 
invoked.  However,  the  mathematical  specification  of  a  function  depends  on  the  format  of  the  input  to 
that  function.  For  example,  although  demultiplexing  and  channel  identification  can  occur  in  either 
order,  the  specification  of  channel  identification  varies  according  to  whether  the  identification  is  done 
on  multiplexed  or  demultiplexed  data.  Hence,  we  could  not  give  a  mathematical  specification  of  SCP’s 
individual  functions  without  arbitrarily  selecting  an  order  in  which  the  functions  are  to  be  invoked. 

Another  more  serious  problem  became  apparent.  The  functional  decomposition  that  we  derived 
was  not  unique;  other  decompositions  are  possible.  Including  a  single  functional  decomposition  in  the 
requirements  document  would  force  us  to  state  that  the  designer  did  not  have  to  break  the  system  into 
the  same  functions  used  to  specify  it.  The  danger  of  this  approach  is  that  a  designer  who  initially 
understands  the  system  in  terms  of  the  given  decomposition  might  find  it  difficult  to  design  the  system 
in  terms  of  another  decomposition,  even  if  a  better  one  exists.  Hence,  the  requirements  document  was 
once  again  usurping  the  designer’s  job. 

Both  of  these  problems  are  exacerbated  by  the  fact  that  there  are  constraints  on  some  of  the  func¬ 
tions;  for  example,  the  use  of  certain  cryptographic  hardware  is  required.  Thus  the  designer  could 
ignore  neither  the  functional  decomposition  nor  the  order  of  function  invocation  offered  in  the  docu¬ 
ment.  The  designer  would  have  to  be  constantly  convinced  that  changes  made  in  the  given  decomposi¬ 
tion  did  not  affect  those  parts  of  the  decomposition  (that  is,  the  constraints)  that  were  not  candidates 
for  modification.  This  could  strongly  discourage  designers  from  trying  functional  decompositions 
different  from  the  original. 

USING  EXTERNAL  FUNCTIONS 

Having  convinced  ourselves  of  the  inadequacy  of  description  via  functional  decomposition,  we 
abandoned  it.  Nevertheless,  we  still  needed  to  describe  what  SCP  was  required  to  do  or,  more 
specifically,  how  to  specify  acceptable  output  values. 

To  accomplish  this,  we  exploited  the  fact  that  systems  external  to  SCP  perform  a  series  of 
transformations  on  the  original  message  data  to  produce  the  SCP  input.  We  refer  to  these  transforma¬ 
tions  as  the  external  functions.  We  decided  to  describe  the  SCP  output,  not  in  reference  to  the  input  (to 
which  it  bears  no  natural  relation),  but  as  a  function  of  the  original,  human-readable  message  data. 
Moreover,  we  also  described  the  input  as  a  function  of  the  original  message  data.  Our  approach  pro¬ 
vides  a  formal  description  of  each  external  function  and  specifies  the  order  in  which  the  external  func¬ 
tions  are  invoked.  Describing  this  order  is  not  an  overspecification,  because  it  is  fixed  by  what  actually 
happens  externally. 

Once  the  external  functions  and  the  order  in  which  they  are  invoked  are  described,  the  formal 
requirements  of  SCP  are  (1)  to  reconstruct  the  original  data  and  (2)  to  convert  it  to  the  output  charac¬ 
ter  set.  The  latter  step  is  performed  by  the  output  functions.  By  specifying  only  the  external  functions 
and  the  output  functions,  the  requirements  document  gives  a  clear,  precise  description  of  the  external 
behavior  of  SCP,  without  describing  how  the  system  performs  the  reconstruction.  The  actual  decompo¬ 
sition  of  SCP  into  functions  and  the  selection  of  the  order  in  which  functions  are  invoked  are  decisions 
that  are  left  for  the  software  designers. 

As  an  example,  consider  a  system  S  similar  to  SCP  but  with  only  two  external  functions.  Call  the 
functions  /  and  g,  and  assume  that  /  is  performed  first.  Then,  let  F  =  g  ■  f,  where  •  represents  func¬ 
tional  composition.  The  requirement  of  S  is  that  it  perform  F\  where  F'  is  defined  to  be  the  inverse  of 
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F. \  i.e.,  F'  •  F  —  /,  where  /  is  the  identity  function.  In  describing  S  in  this  manner,  we  make  no  deci¬ 
sions  about  which  function  is  inverted  first.  We  also  leave  open  the  nature  of  the  functional  decompo¬ 
sition  used  to  implement  F'. 

Our  original  approach,  based  on  functional  decomposition,  gave  us  specifications  of  the  form 
B implies  output  :=  G  (inputs), 

where  B  is  a  predicate  and  each  SCP  output  is  expressed  as  a  function  G  of  one  or  more  input  values. 
The  problem  was  that  the  complexity  of  G  forced  us  to  make  premature  design  decisions  when  we  tried 
to  specify  it  as  a  mathematical  expression.  In  contrast,  the  new  approach,  in  the  simplest  case,  pro¬ 
duces  specifications  of  the  form 

B  implies  (input  =  F(data)  &  output  data),  (1) 

where  F  is  a  function  of  the  original  message  data.  This  maintains  the  discipline  of  abstract 
specification  while  allowing  for  functional  complexity.  This  form  of  specification  moves  the  decomposi¬ 
tion  from  SCP  to  F,  which  is  external  to  SCP. 

In  specifying  SCP,  we  actually  use  a  more  general  form  of  (1),  i.e., 

B  implies  (input  =  F(data)  &  output  :=  //(data)), 

where  F  represents  the  series  of  transformations  performed  by  the  external  functions  and  H  the 
transformations  performed  by  the  output  functions.  The  exact  definitions  of  H  and  F  depend  on  the 
condition  B  that  is  true.  Note  that  direct  specification  of  //,  the  translation  of  the  original  data  to  the 
required  output  format,  does  not  violate  abstract  specification.  Because  of  its  simplicity,  H  can  be 
described  without  decomposing  it  into  smaller  functions. 

This  new  approach  can  be  used  to  give  abstract  specifications  for  any  one  of  a  class  of  systems  in 
which  there  is  no  simple  relation  between  the  input  and  the  output  but  there  is  a  simple  relationship 
(1)  between  some  set  of  data  D  and  the  input  and  (2)  between  D  and  the  output.  This  includes  cases 
where  the  input  has  been  encoded,  garbled,  or  otherwise  changed. 

FURTHER  FEATURES  OF  OUR  APPROACH 

The  generation  of  a  requirements  document  for  SCP  led  us  to  consider  two  broad  issues.  One 
issue  concerned  the  general  approach  to  be  used;  as  we  have  said  previously,  we  needed  an  approach 
consistent  with  the  methodology  of  abstract  specification.  Another  issue  concerned  what  specific  formal 
techniques  we  should  adopt  to  document  the  requirements.  In  the  appendix,  we  describe  a  sample  sys¬ 
tem  that  illustrates  many  of  the  formal  techniques  that  we  formulated  and  applied  in  Ref.  4.  Here,  we 
briefly  discuss  some  of  these  techniques.  To  illustrate  two  of  them,  we  draw  upon  parts  of  the 
specification  given  in  the  appendix. 

Table  Format 

We  decided  to  specify  each  external  function,  as  well  as  each  output  function,  in  a  table.  The 
table  format,  which  is  identical  for  both  the  external  and  the  output  functions,  makes  it  easy  to  answer 
specific  questions.  In  addition,  it  helps  in  identifying  missing  information  and  inconsistencies. 

Table  1  is  used  to  specify  an  external  function  named  MUX.  The  table  consists  of  several  sec¬ 
tions.  The  syntax  section  defines  the  data  types  of  the  function's  parameters.  The  uses  part  identifies 
any  functions  that  are  called  by  the  function  being  defined,  thus  making  the  effects  of  changes 
apparent.  The  description  section  describes  in  prose  what  the  function  does;  it  motivates  the  formal 
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Table  1  —  Completed  Table  for  an  External  Function 

External  function:  Multiplexor 

Function  short  name:  MUX 

Syntax:  MUX(%characterstring%,  %characterstring%)  — +  %characterstring% 

Description:  MUX  combines  two  character  strings,  where  each  string  is 

~~  ~  associated  with  a  different  channel,  into  a  single  string.  The 

multiplexing  is  done  on  a  character  basis;  that  is,  in  the 
output,  character  1  of  the  first  string  is  followed  by  character 
1  of  the  second  string,  character  2  of  the  first  string, 
character  2  of  the  second  string,  etc. 

Uses:  None 

Notation:  a^  =  a^  where  is  a  %character% 

a2  =  a2,l*,>a2,m  where  a2,  i  *-s  a  ^character% 

b  =  b^...bh  where  b^  is  a  %character%  and  h  »  2*m 

Semantics:  MUX(a^,  a 2 )  =  b  ==+ 

(i)  (j)  (E  g)  (1  le  i  le  2  &  1  le  j  le  m  ==+ 
bg  =  aitj  &  g  -  ( j-1 )*Z  +  i) 

Input  parameter  restrictions :  None 


description  given  in  the  semantics  section.  The  specification  language  used  in  the  semantics  section  is 
an  extension  of  first-order  predicate  calculus,  (See  the  appendix  for  an  explanation  of  the  special  nota¬ 
tion  used  in  the  semantics  section.) 

Constraints 

In  addition  to  specifying  what  SCP  must  do,  the  requirements  document  also  describes  the  con¬ 
straints  on  the  implementation.  We  found  that  the  same  table  format  used  to  describe  the  external  and 
the  output  functions  could  be  used  to  describe  some  of  the  constraints,  such  as  the  way  in  which  error 
detection  and  correction  is  implemented. 

Not  all  of  the  SCP  constraints  can  be  described  via  the  tabular  format.  Some  functions  required 
of  SCP,  for  example  decryption,  must  be  implemented  via  special  hardware.  Thus,  Ref.  4  states  expli¬ 
citly  that  the  SCP  software  must  pass  data  to,  and  receive  results  from,  special  hardware.  English 
prose,  rather  than  formal  techniques,  is  used  to  describe  the  constraints  on  decryption  and  other  similar 
constraints. 

Data  Types  and  Data  Items 

One  section  of  Ref.  4  defines  many  different  data  types.  All  data  objects  that  exhibit  the  same 
externally  visible  behavior  are  said  to  belong  to  a  given  data  type.  Reference  4  defines  each  data  type 
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by  describing  the  operations  with  which  it  is  associated  and  uses  the  notation  %data  type%  to  identify 
them.  Examples  of  SCP  data  types  are  %characterstring%  and  %qualityindicator%. 

Another  section  of  Ref.  4  defines  several  data  items.  Each  data  item  belongs  to  one  of  three 
classes:  input  data  items ,  data  items  transmitted  to  SCP  from  external  software;  output  data  items ,  data 
items  transmitted  by  SCP  to  external  software;  and  pre-input  data  items ,  data  items  that  are  inputs  to 
one  or  more  of  the  external  functions.  These  are  denoted  as  /input  data  item/,  //output  data  item//, 
and  /pre-input  data  item//. 

The  SCP  requirements  document  uses  a  table  to  describe  each  data  item.  The  table  provides  an 
acronym  for  the  item,  identifies  its  data  type,  and  describes  the  item  in  English  prose.  Table  2  describes 
an  input  data  item  named  /MUXDATA/. 


Input  Data  Item: 

Acronym: 

Description: 


Type: 

Error  Conditions: 


Table  2  —  Completed  Table  for  an  Input  Data  Item 
Multiplexed  Data 
/MUXDATA/ 

/MUXDATA/  contains  the  multiplexed  channels  of  message 
data.  It  is  the  input  to  T. 

%characterstring% 

None 


"Virtual"  External  Functions 

In  some  cases,  the  formal  description  of  the  external  functions  is  simplified  if  we  make  assump¬ 
tions  that  differ  from  what  actually  occurs.  Thus  some  of  the  external  functions  are  virtual. 

An  example  is  the  external  function  GARBLE,  which  is  an  idealization  of  the  process  that  intro¬ 
duces  bit  errors  into  the  message  data.  The  assumption  made  relative  to  GARBLE  is  that  no  more  than 
a  single  bit  error  can  occur  in  each  transmitted  character.  Such  an  assumption  is  necessary  because  of 
the  limited  error-correcting  capability  of  the  error-correction  scheme  that  SCP  is  constrained  to  imple¬ 
ment.  To  avoid  confusion,  the  number  of  external  functions  whose  description  differs  from  reality  was 
kept  small.  Moreover,  in  an  early  section  of  the  requirements  document,  we  explicitly  state  each  sim¬ 
plifying  assumption,  along  with  a  description  of  what  actually  happens  and  a  list  of  the  external  func¬ 
tions  that  are  affected. 

COMPARISON  WITH  THE  APPROACH  USED  IN  THE  A-7  PROJECT 

The  SCP  requirements  document  uses  many  of  the  techniques  that  were  used  in  the  A-7  require¬ 
ments  document  (1,  5],  These  include  symbolic  names  for  data  items  and  values,  special  brackets  to 
indicate  data  items,  standard  forms,  and  special  tables  for  consistency  and  completeness  checking. 
While  many  of  the  more  general  techniques  used  in  Ref.  5  were  directly  applicable  to  our  document, 
the  technique  used  to  describe  the  required  A-7  functions  was  not. 
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In  describing  functions,  the  A-7  team  faced  problems  similar  to  those  confronted  in  the  SCP  pro¬ 
ject.  The  relationship  between  the  A-7  outputs  and  inputs  could  be  highly  complex.  Moreover,  the  A- 
7  team  needed  an  approach  that  described  the  required  behavior  without  making  premature  design  deci¬ 
sions. 


The  A-7  project  team  initially  planned,  as  we  did,  to  express  each  output  as  a  mathematical  func¬ 
tion  of  input  values.  However,  they  rejected  this  approach  because  it  forced  developers  to  describe  an 
implementation  [1].  We  can  illustrate  this  by  considering  the  A-7  function  that  displays  the  current 
altitude.  Altitude  can  be  measured  in  a  number  of  ways.  Under  some  circumstances  the  A-7  software 
may  read  the  barometric  altimeter  to  compute  altitude,  whereas  under  different  circumstances  it  may  be 
better  to  read  the  altitude  as  measured  by  radar.  The  choice  is  an  implementation  decision  and  as  such 
should  not  be  specified  in  the  requirements  document. 

The  technique  ultimately  used  in  the  A-7  project  expresses  output  values  as  functions  of  condi¬ 
tions  and  events  external  to  the  system.  Conditions  are  predicates  that  characterize  some  aspect  of  the 
system  for  a  measurable  period  of  time,  but  they  are  not  necessarily  system  inputs;  an  event  occurs 
when  the  value  of  a  condition  changes.  In  terms  of  the  notation  we  used  earlier,  each  A-7  function  is 
described  via  one  or  both  of  the  following  two  forms: 

B  implies  output  k, 

where  k  is  a  constant,  or 

B  implies  output  :=  F(xx,  x2,  ...  ,  jc„), 

where  F  is  a  function,  and  each  x,  is  either  another  A-7  output  or  an  externally  visible  factor  of  the  air¬ 
craft  or  its  environment. 

Examples  of  externally  visible  factors  are  altitude,  air  pressure,  longitude,  ground  range,  and  wind 
velocity.  Some  of  these  factors,  for  example  altitude,  can  be  measured  directly  and  are  thus  inputs  to 
the  A-7  software.  Other  factors,  such  as  air  pressure  and  wind  velocity,  cannot  be  measured  directly 
and  must  be  computed  from  inputs.  A  dictionary  included  in  Ref.  5  defines  each  externally  visible  fac¬ 
tor  informally  with  English  prose.  For  example,  longitude  is  defined  as  the  "longitude  coordinate  of  the 
present  position,"  and  ground  range  as  the  "horizontal  distance  to  some  point."  How  to  compute  these 
factors  is  not  specificed  m  the  document  but  is  left  for  the  system  implementors. 

Typically,  the  function  /'is  quite  simple  and  has  only  a  single  parameter.  Often,  Fis  the  identity 
function.  In  other  cases,  English  prose  is  used  to  define  the  relationship  between  the  external  factor(s) 
and  the  required  output.  For  example,  one  A-7  output  item  is  defined  as  "half  of  Isteering  error!  from 
Flight  Path  Marker,"  where  '.steering  error!  is  an  externally  visible  factor. 

The  significant  difference  between  the  two  approaches  lies  in  the  degree  to  which  formalism  is 
used.  As  noted  above,  the  functional  requirements  of  SCP  are  defined  rigorously  in  a  specification 
language  based  on  first-order  predicate  calculus.  The  definition  of  the  A-7  functions  is  more  informal, 
relying  on  the  extensive  use  of  English  prose  and  tables  to  describe  the  many  externally  visible  factors 
and  the  functions  themselves. 

The  more  formal  techniques  used  in  the  SCP  document  are  possible  due  to  the  presence  of  the 
external  functions.  Because  there  is  nothing  in  the  A-7  environment  that  is  analogous  to  the  externa! 
functions,  there  is  no  obvious  way  to  define  the  A-7  functions  more  formally. 
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Likewise,  the  A-7  approach  is  not  feasible  for  SCP.  In  the  SCP  environment,  there  are  no  exter¬ 
nally  visible  factors  with  a  commonly  accepted  definition;  thus  Ref.  4  cannot  appeal  to  well-known 
physical  phenomena  such  as  latitude,  longitude,  and  altitude.  Instead,  it  refers  to  phenomena,  such  as 
cryptographic  devices  and  error  detection  and  correction  algorithms,  whose  specific  features  vary  from 
one  application  to  the  next. 

While  they  exhibit  some  differences,  the  two  approaches  also  have  important  similarities.  Each 
provides  a  clear  and  precise  description  of  a  system’s  required  external  behavior.  Each  leads  to  a 
requirements  document  that  is  organized  for  ease  of  change.  Both  avoid  overspecification:  decisions 
about  software  design  and  implementation  are  not  made  in  the  requirements  document  but  are  post¬ 
poned  until  the  later  stages  of  development. 

CONCLUSIONS 

Even  though  it  seemed  impossible  initially,  a  closer  look  at  the  SCP  application  indicated  that  an 
abstract  specification  of  the  required  functions  was  feasible.  The  abstract  approach  produced  a  precise 
statement  of  the  requirements  and,  at  the  same  time,  encouraged  us  to  avoid  premature  design  deci¬ 
sions.  More  generally,  the  generation  of  a  formal  requirements  document  forced  us  to  seek  clarification 
and  further  information  about  the  requirements.  The  result  is  a  document  that  is  much  closer  to  a 
complete  and  consistent  statement  of  the  SCP  requirements  than  it  would  have  been  otherwise. 

Our  experience  also  emphasized  the  importance  of  having  models.  As  we  have  stated  earlier, 
many  of  the  techniques  used  in  the  A-7  requirements  document  were  directly  applicable  to  our  project. 
The  examples  provided  by  Refs.  1  and  5  facilitated  our  understanding  of  the  techniques  and  simplified 
our  application  of  them  to  a  different  system. 

We  hope  that,  in  a  similar  fashion.  Ref.  4  will  also  serve  as  a  model.  There  are  numerous  sys¬ 
tems  whose  function  is  to  undo,  in  some  sense,  transformations  that  have  been  performed  externally. 
This  class  includes  not  only  many  systems  in  which  input  has  been  multiplexed,  encoded,  or  garbled, 
but  any  system  that  is  required  to  convert  data  back  to  some  original  form.  An  example  of  such  a  sys¬ 
tem  is  one  that  retrieves  data  that  have  been  hashed  into  an  array.  It  is  more  natural  to  describe  such  a 
system  in  terms  of  the  hashing  algorithm  used  than  in  terms  of  a  particular  dehashing  algorithm. 
Further,  such  an  approach  permits  an  implementation  where  dehashing  is  abandoned  in  favor  of,  say. 
linear  search  of  the  array.  By  the  application  of  techniques  similar  to  those  illustrated  in  Ref.  4.  it 
should  be  possible  to  produce  abstract  specifications  for  the  requirements  of  such  systems. 
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Appendix 

THE  SCP  SPECIFICATION  TECHNIQUES 


INTRODUCTION 

This  appendix  illustrates  the  specification  techniques  used  in  the  SCP  requirements  document  (4] 
Summarized  here  is  a  sample  system  that  performs  a  small  subset  of  the  functions  that  SCP  will  per¬ 
form.  The  SCP  techniques  are  used  to  provide  an  abstract  specification  of  the  system's  requirements. 

The  Sample  System 

The  system,  named  T \  receives  two  channels  of  data  that  have  been  encrypted  and  then  multi¬ 
plexed.  The  system  T  is  required  to  convert  each  channel  of  data  to  its  form  prior  to  encryption  and 
then  translate  the  data  to  the  required  output  format.  Using  the  SCP  approach,  we  must  therefore 
specify  two  external  functions,  encryption  and  multiplexing,  and  one  output  function,  translation. 

Comments  on  the  Specification 

To  reduce  its  complexity,  the  sample  system  given  here  describes  the  needed  data  types  infor¬ 
mally.  Moreover,  we  have  not  included  a  description  of  the  constraint  that  decryption  be  performed  by 
a  specific  hardware  device.  The  reader  is  referred  to  Ref.  4  for  an  illustration  of  more  formal  tech¬ 
niques  for  specifying  such  requirements.  Finally,  we  have  not  included  a  specification  for  the  function 
CTABLE,  which  defines  the  mapping  between  the  original  character  code  and  the  output  character 
code. 


T:  REQUIREMENTS  SPECIFICATION 

The  specification  is  divided  into  four  sections.  Section  1  identifies  the  data  types  and  data  items 
that  T  requires.  Section  2  specifies  two  external  functions,  ENCRYPT  and  MUX,  while  Section  3 
describes  the  output  function,  TRANSLATE.  Each  function  is  specified  via  a  table;  the  notation  used 
in  the  semantics  field  of  each  table  is  defined  in  Table  Al.  Section  4  defines  the  relationship  between 
T’s  input  and  its  output  using  the  external  functions,  the  output  function,  and  the  data  items. 


Table  Al  —  Notation  Used  in  Function  Tables 


Symbol 

Meaning 

(i) 

for  all  i 

(Eg) 

there  exists  g 

=  =  + 

implies 

~  + 

is  mapped  to 

le 

is  less  than  or  equal  to 

& 

logical  AND 
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1.  Data  Types  and  Data  Items 

The  only  data  types  used  in  the  specification  are  the  standard  ones,  %character%  and  %character- 
string%.  The  data  items  required  to  specify  T  are  presented  below. 


1.1  Pre-Input  Data  Items 


1.1.1 


Pre-Input  Data  Item:  Data  for  Channel  i 

Acronym:  /DATAi//  i  =  1,2 

Description:  /DATAi//  is  the  original,  human-readable  data,  associated 

with  channel  i,  before  it  has  been  transformed  by  any  of 
the  external  functions. 


Type: 


Zcharac ter string? 


Error  Conditions:  None 


1.1.2 

Pre-Input  Data  Item:  Encrypted  Data  for  Channel  i 

Acronym:  /ENCDATAi//  i  *  1,2 


Description: 

Type: 


/ENCDATAi//  is  the  data  associated  with  channel  i  after  it 
has  been  encrypted  and  before  it  has  been  multiplexed. 

?charac ter string? 


Error  Conditions:  None 
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1.2  Input  Data  Item 


1.2.1 


Input  Data  Item;  Multiplexed  Data 
Acronym:  /MUXDATA/ 


Description;  /MUXDATA/  contains  the  multiplexed  channels  of  message 

data.  It  is  the  input  to  T. 


Type;  %charac terstring% 

Error  Conditions:  None 


1.3  Output  Data  Item 


1.3.1 


Output  Data  Item;  Processed  Data  for  Channel  i 
Acronym;  //PROCDATAi//  i  *  1,2 


Description:  //PROCDATAi//  is  the  original,  human-readable  data 

associated  with  channel  i  after  it  has  been  translated  to 
the  output  character  set.  It  is  the  output  of  T. 


Type;  %characterstring% 

Error  Conditions:  None 
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External  Functions 


External  function: 


Encryptor 


Function  short  name: 


ENCRYPT 


Syntax: 


ENCRYPT(%characterstr ingX)  — +  %characterstring% 


Description:  ENCRYPT  is  an  encryption  function  performed  on  a 

character-by-character  basis  by  the  XYZ  encryption  device. 
ENCRYPT  maps  each  character  of  the  input  string  into  a  character 
in  the  same  relative  position  in  the  output  string.  The  mapping 
is  performed  in  such  a  way  that  the  XYZ  decryption  device  can 
perform  the  inverse  operation. 


Uses: 


Notation: 


X  =*  xj...xn  where  x^  is  a  ZcharacterZ 
y  a  yi...yn  Where  y£  is  a  ^character* 


Semantics:  ENCRYPT(x)  *  y  »*+ 


(i)  (1  le  i  le  n  «♦  y^  is  the  XYZ-encryption  of  x^) 


Input  parameter  restrictions:  1  le  n  le  5000 
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2.2 

External  func  tioni  Multiplexor 

Function  short  name;  MUX 

Syntax;  MUX(%characterstring%,  %charac terstring%)  — +  %charac terstring% 

Description:  MUX  combines  two  character  strings,  where  each  string  is 

associated  with  a  different  channel,  into  a  single  string.  The 
multiplexing  is  done  on  a  character  basis;  that  is,  in  the 
output,  character  1  of  the  first  string  is  followed  by  character 
1  of  the  second  string,  character  2  of  the  first  string, 
character  2  of  the  second  string,  etc. 

Uses:  None 

Notation:  a |  =  aj  i...aj  m  where  a^  j  is  a  %character% 

a2  =  a2  l**‘a2,m  where  32,  i  ’•s  a  %character% 
b  =  b^...b^  where  b^  is  a  %character%  and  h  =  2*m 

Semantics:  MUX(a^,  a2)  =  b  ==+ 

(i)  (j)  (Eg)  (1  le  l  le  2  &  1  le  j  le  m  ==+ 
bg  *  aif j  &  g  =  (j-l)*2  +  i) 

Input  parameter  restrictions:  None 
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3.  Output  Function 


3.1 


Output  function:  Translate 

Short  name:  TRANS 

TRANS(%characterstr ing%)  — +  %characterstring% 


Syntax: 


Description:  TRANS  translates  a  character  string  from  one  character  set  to 

another.  Each  character  in  the  input  string  is  replaced  by  the 
appropriate  character  to  produce  the  output  string. 


Dses: 

Notation: 


CTABLE 


x  =  x^...xn  where  x£  is  a  XcharacterZ 
y  =*  yi*..yn  where  y£  is  a  ^character! 


Semantics: 


TRANS (x)  *  y  — • + 

(i)  (1  le  i  le  n  «»+  y£  ■  CTABLE(x£>) 


Input  parameter  restrictions:  None 


4.  Specification  of  T 

4.1  Specification  of  T*s  Input 

(1)  For  i  *  1,2 

/ENCDATAi//  *  ENCRYPT ( /DATAi//) 

(2)  /MUXDATA/  -  MUX( /ENCDATAI//,  /ENCDATA2/ /) 

4.2  Specification  of  T's  Output 

For  i  ■  1,2 

//PROCHANi//  »  TRANS< /DATAi//) 
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